src/main/java/org/scoula/domain/chat/service/ChatServiceImpl.java (1)

636-651: isUserInContractChatRoom 접근 체크 로직 불일치 가능성

현재 구현은 userCurrentChatRoom(일반 채팅방 ID를 담는 맵)에서 contractChatId와 비교합니다. 일반/계약 채팅방 ID 네임스페이스가 다르다면 항상 false가 나올 수 있습니다. 계약 채팅방 입장/퇴장 시점을 별도로 기록하거나, 공용 맵을 사용하더라도 동일 ID 체계를 보장해야 합니다.

제안:

• 별도의 맵 도입: Map<Long, Long> userCurrentContractChatRoom
• 입장/퇴장 트래킹 메서드 추가: setUserCurrentContractChatRoom/removeUserFromCurrentContractChatRoom
• isUserInContractChatRoom은 해당 맵을 참조
• 혹은 기존 맵을 재사용하려면 저장하는 ID가 항상 "계약 채팅방 ID"가 되도록 호출부 전반을 정렬

원하시면 적용 패치를 제안드리겠습니다.

src/main/java/org/scoula/domain/chat/service/ContractChatServiceImpl.java (1)

1596-1724: 복잡한 메서드를 더 작은 단위로 분리하세요

saveFinalSpecialContract 메서드가 130줄이 넘어 너무 깁니다. 로직을 더 작은 메서드로 분리하면 가독성과 테스트 용이성이 향상됩니다.

+    private FinalSpecialContractDocument.FinalClause findValidClauseFromRounds(
+            Long contractChatId, Integer clauseOrder, Long startRound) {
+        for (Long searchRound = startRound; searchRound >= 1L; searchRound--) {
+            Optional<SpecialContractDocument> docOpt = 
+                specialContractMongoRepository.findSpecialContractDocumentByContractChatIdAndRound(
+                    contractChatId, searchRound);
+            
+            if (docOpt.isPresent()) {
+                Optional<SpecialContractDocument.Clause> clauseOpt = 
+                    findValidClauseInDocument(docOpt.get(), clauseOrder);
+                
+                if (clauseOpt.isPresent()) {
+                    SpecialContractDocument.Clause clause = clauseOpt.get();
+                    log.info("특약 {}번 저장 완료 (라운드 {}): {}", clauseOrder, searchRound, clause.getTitle());
+                    return FinalSpecialContractDocument.FinalClause.builder()
+                        .order(clauseOrder)
+                        .title(clause.getTitle().trim())
+                        .content(clause.getContent().trim())
+                        .build();
+                }
+            }
+        }
+        return null;
+    }
+    
+    private Optional<SpecialContractDocument.Clause> findValidClauseInDocument(
+            SpecialContractDocument doc, Integer clauseOrder) {
+        return doc.getClauses().stream()
+            .filter(clause -> clause.getOrder() != null && clause.getOrder().equals(clauseOrder))
+            .filter(clause -> isValidClause(clause))
+            .findFirst();
+    }
+    
+    private boolean isValidClause(SpecialContractDocument.Clause clause) {
+        return clause.getTitle() != null && !clause.getTitle().trim().isEmpty()
+            && clause.getContent() != null && !clause.getContent().trim().isEmpty();
+    }

src/main/java/org/scoula/domain/chat/service/ContractChatServiceImpl.java (1)

10-10: 와일드카드 임포트 사용을 지양하세요

Controller와 동일하게 와일드카드 임포트를 사용하고 있습니다. 명시적 임포트를 사용하는 것이 좋습니다.

src/main/java/org/scoula/domain/chat/controller/ContractChatControllerImpl.java (2)

12-12: 와일드카드 임포트 사용을 지양하세요

---

903-903: 일관성 없는 파라미터 타입

Controller 인터페이스의 주석과 동일하게, FinalContractDeletionResponseDto가 확정 수락 메서드에 사용되고 있습니다.

config-submodule (1)

1-1: 메시징/알림 트랜잭션 경계·재시도·아이도템포턴시 고려

프리컨트랙트 저장 직후 URL 링크 메시지 전송 로직이 포함된 것으로 보입니다. 다음을 반영하면 신뢰성이 올라갑니다.

• 트랜잭션 커밋 이후 비동기 발송(트랜잭션 동기화 이벤트/아웃박스 패턴).
• 메시지 아이디 기반 중복 방지(Idempotency-Key).
• SSE 재연결/오프라인 백필 전략, WebSocket 구독 권한 재검증.
• 장애 시 재시도(지수 백오프)와 데드레터 채널 운영.

src/main/java/org/scoula/domain/chat/dto/FinalContractDeletionResponseDto.java (1)

5-13: Lombok 애노테이션 중복 제거 및 스타일 일관성

@DaTa와 @Getter/@Setter를 동시에 사용하고 있습니다. 중복이며, 다른 DTO(FinalContractModificationResponseDto)와 스타일도 다릅니다. 한 쪽만 유지하는 게 좋습니다. 아래처럼 @DaTa를 제거해 ModificationResponseDto와 맞추길 권장합니다.

-@Data
 @Builder
 @AllArgsConstructor
 @NoArgsConstructor
 @Getter
 @Setter
 public class FinalContractDeletionResponseDto {
     private boolean accepted;
 }

src/main/java/org/scoula/domain/chat/service/ContractChatServiceInterface.java (4)

247-249: 메시지 비존재 미완료 특약 조회 메서드의 스키마/인덱스 가정 명시 필요

getIncompleteSpecialContractsWithoutMessage의 "message 없음" 정의(필드 미존재 vs 공백 문자열 vs 빈 배열)를 명확히 해주세요. 또한 repository 레벨에서 해당 조건을 효율적으로 처리하기 위한 인덱스 전략을 문서/주석로 남기는 것을 권장합니다.

---

265-266: AI 메시지 메서드 네이밍/역할 정의 통일

AiMessage, AiMessageBtn, AiMessageNext의 역할/차이를 인터페이스 주석으로 명확히 해주세요. 호출 순서 보장, 버튼 payload 스펙 등도 함께 정의되면 구현체/호출부 정합성 유지에 도움이 됩니다.

---

267-276: 최종 특약 수정 요청/응답 API 계약 명확화 및 예외 규격화

역할(임대인만 요청 가능, 임차인만 응답 가능), 중복 요청 방지, 동시성 처리(동일 조항 동시 요청)에 대한 계약을 자바독으로 명시하고, 권한/상태 오류 시 던지는 예외 타입을 통일해 주세요.

예시 자바독(패턴 제안):

/**
 * 임대인이 특정 조항에 대해 최종 특약 수정 요청을 등록합니다.
 *
 * 권한: owner만 호출 가능
 * 전제: 해당 contractChatId가 존재하고, 최종 특약 확정 전 상태여야 함
 * 제약: 동일 clauseOrder에 대해 pending 요청이 이미 존재하면 BusinessException
 *
 * @throws IllegalArgumentException null 파라미터
 * @throws BusinessException 권한 불일치, 상태 불일치, 중복 요청
 */

---

277-304: Map 반환 타입을 전용 DTO로 치환 고려

acceptFinalContractConfirmation, acceptFinalContractDeletion, respondToFinalContractDeletionRequest 등이 Map<String, Object>를 반환하고 있습니다. 스키마가 불명확해 프론트/호출부에서 타입 안정성이 떨어집니다. 전용 DTO를 도입해 계약을 명확히 해주세요.

예: FinalContractActionResultDto { status, message, updatedDocumentId, ... }

src/main/java/org/scoula/domain/chat/controller/ContractChatController.java (1)

10-10: 와일드카드 임포트 사용을 지양하세요

org.scoula.domain.chat.dto.*와 같은 와일드카드 임포트 대신 필요한 클래스를 명시적으로 임포트하는 것이 좋습니다. 이는 코드의 가독성을 높이고 사용되는 클래스를 명확히 파악할 수 있게 합니다.

-import org.scoula.domain.chat.dto.*;
+import org.scoula.domain.chat.dto.ContractChatMessageRequestDto;
+import org.scoula.domain.chat.dto.SpecialContractUserViewDto;
+import org.scoula.domain.chat.dto.FinalContractModificationRequestDto;
+import org.scoula.domain.chat.dto.FinalContractModificationResponseDto;
+import org.scoula.domain.chat.dto.FinalContractDeletionResponseDto;
+import org.scoula.domain.chat.dto.ModificationRequestData;

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Learnt from: CR
PR: ITZEEP/backend#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-12T03:59:30.512Z
Learning: Applies to src/main/java/org/scoula/domain/*/repository/*Repository.java : Place MongoDB repositories under `src/main/java/org/scoula/domain/*/repository/*Repository.java`

src/main/java/org/scoula/domain/chat/service/ChatServiceImpl.java (2)

110-123: URLLINK 프리뷰 처리 추가, 잘 반영됨

"TEXT/URLLINK/FILE"에 대한 미리보기 문구가 명확해져 UX 측면에서 개선되었습니다. 기존 리뷰 지적사항을 정확히 반영했습니다.

---

204-230: URLLINK 알림 케이스 누락 → switch에 케이스 추가 필요

계약 수락 후 발송되는 링크 메시지(type="URLLINK", Line 850)와 정합성을 맞추려면 알림 switch에도 "URLLINK" 케이스를 추가해야 합니다. 현재는 default로 처리되어 제목/본문이 의도와 다를 수 있습니다.

아래 diff처럼 케이스를 보강해 주세요.

                       switch (dto.getType()) {
                           case "TEXT":
                               notificationBody = dto.getContent();
                               notificationTitle = senderName + "님의 새 메시지";
                               break;
+                          case "URLLINK":
+                              notificationBody = "[링크] " + (dto.getContent() != null ? dto.getContent() : "");
+                              notificationTitle = senderName + "님이 링크를 보냈습니다";
+                              break;
                           case "FILE":
                               notificationBody =
                                       "[파일] "
                                               + (dto.getContent() != null
                                                       ? dto.getContent()
                                                       : "파일을 보냈습니다");
                               notificationTitle = senderName + "님이 파일을 보냈습니다";
                               break;
                           case "CONTRACT_REQUEST":
                               notificationBody = "계약을 요청했습니다";
                               notificationTitle = senderName + "님의 계약 요청";
                               break;
                           case "CONTRACT_REJECT":
                               notificationBody = "계약 요청을 거절했습니다";
                               notificationTitle = senderName + "님의 계약 거절";
                               break;
                           default:
                               notificationBody =
                                       dto.getContent() != null ? dto.getContent() : "새 메시지";
                               notificationTitle = senderName + "님의 새 메시지";
                               break;
                       }

Also applies to: 844-851

src/main/java/org/scoula/domain/chat/service/ContractChatServiceImpl.java (3)

50-50: ObjectMapper를 Spring Bean으로 주입받아 사용하세요

ObjectMapper를 직접 생성하지 말고 Spring이 관리하는 Bean으로 주입받아 사용하는 것이 좋습니다. 이렇게 하면 전역 설정을 일관되게 적용할 수 있습니다.

-    private final ObjectMapper objectMapper = new ObjectMapper();
+    private final ObjectMapper objectMapper;

생성자에 ObjectMapper를 추가하면 Spring이 자동으로 주입합니다 (@requiredargsconstructor 사용 중).

---

1063-1088: 중복 코드를 별도 메서드로 추출하세요

최종 특약서 저장 및 상태 업데이트 로직이 중복됩니다. 별도 메서드로 추출하면 유지보수성이 향상됩니다.

+    private Map<String, Object> processFinalContractCompletion(Long contractChatId, String message) {
+        try {
+            FinalSpecialContractDocument finalContract = saveFinalSpecialContract(contractChatId);
+            AiMessageNext(contractChatId, message);
+            contractChatMapper.updateStatus(contractChatId, ContractChat.ContractStatus.ROUND4);
+            
+            return Map.of(
+                "message", "모든 특약이 완료되었습니다!",
+                "completed", true,
+                "finalContractId", finalContract.getId(),
+                "totalFinalClauses", finalContract.getTotalFinalClauses()
+            );
+        } catch (Exception e) {
+            log.error("최종 특약 저장 실패", e);
+            return Map.of("message", "특약은 완료되었지만 최종 저장 중 오류가 발생했습니다.", "completed", true);
+        }
+    }

                  if (remainingIncompleteContracts.isEmpty()) {
-                      try {
-                          FinalSpecialContractDocument finalContract =
-                                  saveFinalSpecialContract(contractChatId);
-
-                          AiMessageNext(contractChatId, "🎉 모든 특약 협상이 완료되었습니다! 최종 특약서가 생성되었습니다.");
-                          contractChatMapper.updateStatus(
-                                  contractChatId, ContractChat.ContractStatus.ROUND4);
-
-                          return Map.of(
-                                  "message",
-                                  "모든 특약이 완료되었습니다!",
-                                  "completed",
-                                  true,
-                                  "finalContractId",
-                                  finalContract.getId(),
-                                  "totalFinalClauses",
-                                  finalContract.getTotalFinalClauses());
-                      } catch (Exception e) {
-                          log.error("최종 특약 저장 실패", e);
-                          return Map.of(
-                                  "message", "특약은 완료되었지만 최종 저장 중 오류가 발생했습니다.", "completed", true);
-                      }
+                      return processFinalContractCompletion(contractChatId, 
+                          "🎉 모든 특약 협상이 완료되었습니다! 최종 특약서가 생성되었습니다.");
                  }

---

2126-2150: JSON 파싱 에러 처리를 개선하세요

JSON 파싱 시 구체적인 예외 타입을 catch하고 더 명확한 에러 메시지를 제공해야 합니다.

-        } catch (Exception e) {
-            log.error("수정 요청 저장 실패", e);
-            throw new RuntimeException("수정 요청 저장 중 오류가 발생했습니다.");
-        }
+        } catch (JsonProcessingException e) {
+            log.error("JSON 직렬화 실패: {}", e.getMessage(), e);
+            throw new IllegalStateException("수정 요청 데이터 직렬화에 실패했습니다.", e);
+        } catch (Exception e) {
+            log.error("Redis 저장 실패: {}", e.getMessage(), e);
+            throw new RuntimeException("수정 요청 저장 중 예기치 않은 오류가 발생했습니다.", e);
+        }

src/main/java/org/scoula/domain/precontract/service/PreContractServiceImpl.java (1)

361-376: 프론트엔드 URL 하드코딩 제거 및 null 체크 추가

환경별(로컬/스테이징/운영) URL 설정이 필요하고, contractChat이 null일 경우 NPE가 발생할 수 있습니다.

     ContractChat contractChat = contractChatMapper.findByContractChatId(contractChatId);
+    if (contractChat == null) {
+        throw new BusinessException(PreContractErrorCode.TENANT_SELECT, 
+            "계약 채팅 정보를 찾을 수 없습니다: contractChatId=" + contractChatId);
+    }

     String contractChatUrls = URL + precontractUrl + (contractChatId.toString()) + ownerUrl;

또한 메시지 타입 "URLLINK"를 상수나 enum으로 관리하는 것을 권장합니다:

-                        .type("URLLINK")
+                        .type(ChatMessageType.URL_LINK)  // 또는 ChatConstants.URL_LINK

src/main/java/org/scoula/domain/precontract/service/OwnerPreContractServiceImpl.java (1)

427-444: 불필요한 메서드 호출 제거 및 null 체크 추가

1. getContractChatStatus() 호출 결과를 사용하지 않으므로 제거해야 합니다
2. contractChat과 chatRoom에 대한 null 체크가 필요합니다
3. 송수신자가 반대로 설정되어 있습니다 (임대인 플로우에서는 owner가 발신자여야 함)

     ContractChat contractChat = contractChatMapper.findByContractChatId(contractChatId);
+    if (contractChat == null) {
+        throw new BusinessException(OwnerPreContractErrorCode.OWNER_SELECT, 
+            "계약 채팅 정보를 찾을 수 없습니다: contractChatId=" + contractChatId);
+    }
+    
     ChatRoom chatRoom =
             chatRoomMapper.findByUserAndHome(
                     contractChat.getOwnerId(),
                     contractChat.getBuyerId(),
                     contractChat.getHomeId());
-    contractChatService.getContractChatStatus(contractChat.getStatus());
+    if (chatRoom == null) {
+        throw new BusinessException(OwnerPreContractErrorCode.OWNER_SELECT, 
+            "채팅방을 찾을 수 없습니다");
+    }
+    
     ChatMessageRequestDto linkMessages =
             ChatMessageRequestDto.builder()
                     .chatRoomId(chatRoom.getChatRoomId())
-                    .senderId(contractChat.getBuyerId())
-                    .receiverId(contractChat.getOwnerId())
+                    .senderId(contractChat.getOwnerId())
+                    .receiverId(contractChat.getBuyerId())
                     .content("계약 채팅방 URL")
                     .type("URLLINK")
                     .build();
     chatService.handleChatMessage(linkMessages);
-    contractChatService.AiMessage(contractChatId, "임대인꼐서 입장하셨습니다! 🤝 이제 계약을 시작합니다.");
+    contractChatService.AiMessage(contractChatId, "임대인께서 입장하셨습니다! 🤝 이제 계약을 시작합니다.");

src/main/java/org/scoula/domain/chat/service/ChatServiceImpl.java (2)

56-61: 환경 URL 필드명과 경로 상수 선언 방식 개선

• 인스턴스 필드명을 대문자(URL)로 두면 타입(java.net.URL)과 혼동될 수 있고 관례에도 어긋납니다. 의미가 드러나도록 frontBaseUrl 등으로 변경 권장.
• 경로 상수는 불변(static final)로 선언하고 상수 네이밍 컨벤션(UPPER_SNAKE_CASE)을 따르는 것을 권장합니다.

아래처럼 정리하면 가독성과 안전성이 올라갑니다.

-      @Value("${front.base.url}")
-      private String URL;
-
-      private String PRECONTRACTURL = "/pre-contract/";
-      private String BUYERURL = "/buyer?step=1";
+      @Value("${front.base.url}")
+      private String frontBaseUrl;
+
+      private static final String PRECONTRACT_PATH = "/pre-contract/";
+      private static final String BUYER_PATH = "/buyer?step=1";

---

842-842: 계약 채팅 URL 조립 시 이중 슬래시/인코딩 이슈 예방

베이스 URL이 슬래시로 끝나는 경우 등 문자열 단순 연결은 이중 슬래시가 생길 수 있습니다. UriComponentsBuilder로 조립하면 안전합니다. (Line 56–61에서 제안한 네이밍을 적용한 예시입니다.)

-          String contractChatUrl = URL + PRECONTRACTURL + (contractChatRoomId.toString()) + BUYERURL;
+          String contractChatUrl = UriComponentsBuilder.fromHttpUrl(frontBaseUrl)
+                  .pathSegment("pre-contract", contractChatRoomId.toString(), "buyer")
+                  .queryParam("step", 1)
+                  .build()
+                  .toUriString();

아래 import 추가 필요:

import org.springframework.web.util.UriComponentsBuilder;

참고: 만약 필드명을 그대로 유지한다면 frontBaseUrl → URL로 변경해 사용하셔도 됩니다.

src/main/java/org/scoula/domain/chat/vo/ContractChat.java (2)

40-53: ROUND4에 대한 라운드 매핑 추가 LGTM

ROUND4 -> 5L 매핑 보완으로 이전 리뷰에서 지적된 누락이 해결되었습니다. 동작 측면 문제 없습니다.

중복 switch/조건을 줄이기 위해 enum에 라운드 인덱스를 속성으로 부여하면 가독성이 좋아집니다.

예시:

public enum ContractStatus {
  STEP0(null), STEP1(null), STEP2(null),
  ROUND0(1L), ROUND1(2L), ROUND2(3L), ROUND3(4L), ROUND4(5L),
  STEP4(null);

  private final Long roundIndex;
  ContractStatus(Long roundIndex) { this.roundIndex = roundIndex; }
  public boolean isRound() { return roundIndex != null; }
  public Long getRoundIndex() { return roundIndex; }
}

// 사용부
public Long getCurrentRound() {
  return (status != null && status.getRoundIndex() != null) ? status.getRoundIndex() : 1L;
}

---

56-64: ROUND4에 대한 라운드 여부 판정 추가 LGTM

라운드 포함 여부에 ROUND4가 반영되었습니다. 추후 유지보수를 위해 enum에 isRound() 유틸을 두는 방식을 권장합니다(위 코멘트 참조).

src/main/resources/org/scoula/domain/precontract/mapper/TenantPreContractMapper.xml (1)

14-19: 쿼리 추가 OK. 포맷팅/스타일 컨벤션 일치 권장

기능은 문제없습니다. 다른 쿼리들과 동일한 들여쓰기/공백 컨벤션을 맞추면 가독성이 좋아집니다.

적용 예시(diff):

-    <select id="selectContractOwnerId" resultType="Long">
-    SELECT owner_id
-    FROM contract_chat
-    WHERE contract_chat_id=#{contractChatId}
-</select>
+    <select id="selectContractOwnerId" resultType="Long">
+        SELECT owner_id
+        FROM contract_chat
+        WHERE contract_chat_id = #{contractChatId}
+    </select>

src/main/java/org/scoula/domain/contract/service/ContractServiceImpl.java (1)

476-482: 검증 메서드 일관성/의미 명확화 제안

• 예외 코드: 소유자 검증 실패에 PreContractErrorCode.TENANT_USER를 재사용하면 의미가 모호합니다. OWNER_USER 또는 UNAUTHORIZED 성격의 코드 신설/사용을 권장합니다.
• 중복 제거: validateUserId(=buyer), validateIsOwner(=owner)를 내부 공통 메서드로 일반화하면 유지보수가 수월합니다.

예시:

private void validateParticipant(Long contractChatId, Long userId, Function<Long, Optional<Long>> idResolver, BusinessException whenNotMatch) {
  Long expected = idResolver.apply(contractChatId).orElseThrow(() -> whenNotMatch);
  if (!userId.equals(expected)) throw whenNotMatch;
}

src/main/java/org/scoula/domain/chat/controller/ContractChatControllerImpl.java (1)

76-83: 중복 제거 OK. 헬퍼 사용으로 인증 로직 간결화됨

getUserIdFromAuthentication 사용으로 기존 중복 코드가 정리되었습니다. 추가로 전 엔드포인트에 Swagger 문서화(@operation 등) 적용을 권장합니다.

예시:

@Operation(summary = "계약 채팅 URL 이동", description = "계약 채팅방 URL을 반환합니다.")
@GetMapping("/{chatRoomId}/moveContractChat")
public ResponseEntity<ApiResponse<String>> moveContractChat(...)

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Learnt from: Whatdoyumin
PR: ITZEEP/backend#40
File: src/main/resources/org/scoula/domain/precontract/mapper/OwnerPreContractMapper.xml:188-192
Timestamp: 2025-08-04T00:51:44.587Z
Learning: In the ITZEEP backend codebase, the owner_precontract_check table uses contract_chat_id as both primary key (PK) and foreign key (FK), so selectOwnerPrecheckId correctly returns contract_chat_id for use in upsertRestoreScope operations. This is confirmed by the join pattern "LEFT JOIN owner_restore_scope ors ON opc.contract_chat_id = ors.owner_precheck_id" in the mapper files.

Learnt from: Whatdoyumin
PR: ITZEEP/backend#40
File: src/main/resources/org/scoula/domain/precontract/mapper/OwnerPreContractMapper.xml:188-192
Timestamp: 2025-08-04T00:51:44.587Z
Learning: In the ITZEEP backend codebase, the owner_precontract_check table uses contract_chat_id as both primary key (PK) and foreign key (FK), so selectOwnerPrecheckId correctly returns contract_chat_id for use in upsertRestoreScope operations.

Learnt from: minnieming
PR: ITZEEP/backend#29
File: src/main/resources/org/scoula/domain/precontract/mapper/TenantPreContractMapper.xml:0-0
Timestamp: 2025-07-30T11:26:48.397Z
Learning: In the ITZEEP backend codebase's precontract domain, the developer prefers to separate MyBatis queries when they have different return types (e.g., Long vs String) rather than combining them into a single query with a resultMap, for clarity and maintainability purposes.